Defining and Referencing Views

Views as a means for showing customized views of processes and collaborations.

Processes and collaborations can be shown in various different diagrams at the same time. These representations are known as views.

Views of processes and collaborations are essentially independent of each other. This means that it is possible for a pool in the defining view of a collaboration to have a referencing view of a process.

Process Definition - Defining View

There is precisely one defining view for each non-empty process and collaboration.

The following applies for the defining view:

All elements of the process and/or collaboration are shown fully.
Modeling can take place in the defining view (if the corresponding rights are available), i.e. elements can be added or deleted.
The diagram which the process or collaboration was initially modeled in is automatically the defining view for the respective element.

Process Definition - Referencing View

Any number of referencing views can be created for each process or collaboration.

The following applies for the referencing view:

Elements can be removed from the diagram.
Subprocesses and/or pools (participants) of a collaboration can be shown as collapsed.
Lanes can be hidden.
The layout can be customized to suit your needs.
The above changes have no influence on the defining view.
The complete process or collaboration can be shown again at any time.
Elements can be selected and renamed; this affects the element itself, which in turn affects the defining view.
Further elements cannot be added or deleted.
A referencing view can be transformed into a defining view. The existing defining view then automatically becomes the referencing view.

The following icons are used in referencing views:

: The referencing view is shown fully, i.e. it contains all elements which are also in the defining view. The layout, i.e. graphical arrangement, may differ.

: The referencing view is shown as incomplete, i.e. there are elements which are shown in the defining view but not in the referencing view.

: The referencing view's semantic conflicts with the defining view, e.g. if a task is in a different lane.

Tip:

Referencing views should only be created when needed and only once modeling of the defining view is complete.
The reason: Changes made to the defining view at a later stage are not automatically carried out in the referencing view. You need to completely show the referencing view to adopt these changes. All previously-made customizations are lost.